1. Field of the Invention
The present invention generally relates to information providing systems and methods for providing information that provide information via a network, and more particularly to an information providing system and a method for providing information that can provide information required by users while user information about the users accessing the provided information can be managed.
Recently, especially in the Internet industry using computers, the Internet has increased its business value yearly and information providing services are frequently performed for authorized users through the World Wide Web (hereinafter called WWW). In this case, authentication technologies are applied so as to confirm whether a user is authorized to use the information providing services. However, when a duplicate use of the same user ID from two different terminals is attempted to connect to the same server at the same time, the duplicate use of the user ID is authenticated. Also, when a user's terminal is not capable of communicating with a server after a user ID is authenticated, the user is not able to access the server from another terminal. Problems of the authentication technologies such as those mentioned above are occurring. Accordingly, current authentication technologies at servers are not enough to manage user access information. It is desired to provide a system in which a server can recognize connection conditions of authenticated users' client terminals (hereinafter referred to as clients).
2. Description of the Related Art
A conventional user authentication on the WWW will now be explained.
FIG. 1 is a schematic illustration of a WWW network structure.
In FIG. 1, the WWW network structure includes a server 200 to provide information, clients 2201 through 220n for users to access the server 200 (hereinafter a reference number 220 is used for a client as a general term) and a public network 210 such as the Internet.
In order to be provided information from the server 200, a user connects a client 220 to the server 200 via the public network 210. After the client 220 is connected to the server 200, the server 200 starts to provide information in accordance with user's requests.
A conventional method for managing user access information about a user that uses a client connecting to a server on the WWW will now be explained.
FIG. 2 is a flowchart showing an example of a conventional WWW user access management.
For example, in order to connect a client 2201 to a server 200, the user A accesses a screen 1 provided by the server 200 (step S1). The server 200 sends an authentication screen for authenticating the user A to the client 2201 (step S2). The user A inputs a user ID and a password to the authentication screen displayed at the client 2201 (step S3). The server 200 authenticates the user A based on the user ID and the password sent from the client 2201 (step S4) and registers the user ID with a session ID (for example, ‘123’) assigned for the user ID to a management table (step S5). Also, the server 200 sets the session ID in the screen 1 and sends the screen 1 to the client 2201 (step S6). At the client 2201, the screen 1 sent from the server 200 is displayed (step S7). In accordance with a user's request, the client 2201 makes a screen 2 request of the server 200 after the client 2201 sends the session ID set in the screen 1 to access screen 2 next (step S8). The server 200 confirms the session ID (‘123’) in the management table based on the request from the client 2201 (step S9). In this case, the session ID (‘123’) is already registered for the user ID. Hence, the server 200 sends a screen 2 to the client 2201 (step S10). The screen 2 is received and displayed at the client 2201.
It is assumed that the user A or another user attempts to connect another client 2202 to the server 200 by using the user ID and the password for the user A.
The client 2202 accesses the screen 1 provided by the server 200 (step S12). The server 200 sends the authentication screen to the client 2202 (step S13). When the authentication screen is displayed at the client 2202, the user inputs the user ID and the password for the user A and the client 2202 sends this information to the server 200. The server 200 confirms the user ID and the password received from the client 2202 (step S15). That is, the server 200 checks whether a session ID for the user ID is registered in the management table or not. In this case, the session ID for the user ID is already registered as ‘123’ and is still being used on the WWW. Hence, the server 200 sends an error message to the client 2202 (step S16). The error message is displayed at the client 2202 (step S17). The message shows the user that no information will be provided. And the access by the user A is denied.
In the conventional user access management on the WWW, the server 200 allows a duplicate login of the user A to obtain information service that is only for authenticated users while the user A is still being provided information from the server 200.
The Internet was originally constructed such that any user connecting to the Internet was allowed to share all information provided by servers connecting to the Internet. In this feature of the Internet, generally, the servers do not have to monitor a screen flow of clients or the like. Thus, some servers do not have a function such as a function for monitoring the screen flow.
In the conventional user access management on the WWW as shown in FIG. 2, it is assumed that the user A accesses another home page provided by another server and a browser of the client 2201 flows to another screen while the user A is provided information by the server 200 on the WWW. In this case, the server 200 does not have a function for monitoring the screen flow of the client 220. Thus, the session ID for the user A remains in the management table of the server 200. After that, the user ID and the password for the user A can not be allowed to access the server 200.
Also, even if the client 2201 used by the user A is not able to communicate with the server 200 because a fault occurs during the session established with the server 200, the server 200 does not have any means to recognize an abnormal state of the client 2201. As a result, the session between the server 200 and the client 2201 remains in the management table. Thus, the user ID and the password for the user A can not be used to access the server 200.